1. Field of the Invention
The present invention relates to systems and methods for testing wireless transceivers, and in particular, such systems and methods in which the wireless transceiver tester and device under test (DUT) operate under the control of firmware for which the test controller and DUT require compatible device drivers.
2. Related Art
Many of today's handheld devices make use of wireless “connections” for telephony, digital data transfer, geographical positioning, and the like. Despite differences in frequency spectra, modulation methods, and spectral power densities, the wireless connectivity standards use synchronized data packets to transmit and receive data.
In general, all of these wireless-connectivity capabilities (e.g., WiFi, WiMAX, Bluetooth, etc.) are defined by industry-approved standards (e.g., IEEE 802.11 and IEEE 802.16) which specify the parameters and limits to which devices having those connectivity capabilities must adhere.
At any point along the device-development continuum, it is generally necessary to test and verify that a device is operating within its standards' specifications. Most such devices are transceivers, i.e., they transmit and receive wireless RF signals. Specialized systems designed for testing such devices typically contain subsystems designed to receive and analyze device-transmitted signals, and to send signals that subscribe to industry-approved standards so as to determine whether a device is receiving and processing the wireless signals in accordance with its standard.
The testing environment generally includes the device under test (DUT), the tester and a controller, e.g., a computer. The computer and tester work together to capture the DUT's transmitted signal and then analyze it against the specifications provided by the underlying standard; and to send tailored signals to the DUT to test its receiver capabilities against the specifications of the underlying standard.
To ensure that DUT, tester and computer cooperate accordingly, there needs to be a complementary relationship between the DUT hardware, tester firmware and drivers employed by the computer to coordinate DUT control and test sequencing. Currently, it is up to the user to figure out which driver goes with which version of firmware, and how best to obtain that driver. The drive to innovate and create more effective and efficient ways to test often involves new driver versions and concomitant development of new firmware. Although it would be convenient for new drivers to be backwards compatible with older versions of firmware, doing so would inhibit innovation. Thus, so long as tester innovation is a key objective, there will be a need to capture the innovation in new driver versions and to pair them up with complementary firmware.
There are three different factors that affect that complementary relationship: the firmware used in the tester, the driver needed to control the DUT, and the driver version used by the computer to control the tester. Any mismatch among the three can impair the testing process. However, imposing a backwards-compatibility restriction on new drivers would constrain innovation.
Test-system manufacturers specify the firmware and create the drivers for their systems. Similarly, chipset makers create drivers that enable integrated circuit (IC) control. Typically, the system user will download these drivers from appropriate websites to the computer. There may, however, be incompatibilities between firmware and driver. For example, the driver may be more recent and not fully complementary with the older firmware. In addition, there may be conflicts between the current version of an IC and different driver versions.
Referring to FIG. 1, a conventional test system environment 10 includes the DUT 12, the tester 14 and controller 16, interconnected substantially as shown. As is well known in the art, the tester 14 is typically implemented in the form of automated test equipment (ATE), such as a vector signal generator (VSG) and vector signal analyzer (VSA), which are well known in the art. Such test equipment 14 includes firmware 14a for controlling the automated test procedures performed by the tester 14.
The controller 16 is typically a computer, e.g., a personal computer (PC). The controller includes software 16a, e.g., its operating system (OS), one or more tester drivers 16b and one or more DUT drivers 16c. These drivers 16b, 16c can be implemented as software stored within or otherwise accessible to the controller 16, or resident in the form of firmware within or otherwise accessible to the controller 16. Such accessibility can include external memory or storage devices (not shown) directly connected to the controller 16 or accessible to the controller 16 by way of a data network (not shown).
The DUT 12 communicates with the tester via a communication link 13, which for testing purposes is a wired connection so as to ensure reliable signal communications between the DUT 12 and tester 14. The controller communicates with the DUT 12 via a communication link 11, e.g., for providing control signals to the DUT 12 and collecting data from the DUT 12. The controller also communicates with the tester via a communication link 15, e.g., for providing control signals to the tester 14 and receiving data from the tester 14. Also, this communication link 15 is used to transfer or update the firmware 14a within the tester 14 (discussed in more detail below).
These bi-directional communication links 11, 13, 15 can be in any of many conventional forms, such as Ethernet, universal serial bus (USB), or other types of which many are well known in the art.
As is well known, proper operation of the test system 10 requires that the tester firmware 14a, controller software 16a and the tester driver 16b be compatible, and further that the DUT 12 and DUT driver 16c are also compatible. Such compatibility among these components is critical, and is normally left to the user to identify and download the appropriate driver. Absent immediate or local availability of the drivers, e.g., on a CD-ROM available to the user, such drivers can be obtained via the Internet 20 from various websites. For example, the controller 16 will typically include a display and a graphic user interface (GUI) through which the user accesses the Internet 20, finds the appropriate one or more websites, and downloads the appropriate tester driver 26b and DUT driver 26c to replace, update or initially serve as the resident tester driver 16b and DUT driver 16c for use by the controller 16.
However, this procedure does not necessarily ensure that the drivers 26b, 26c that had been so located are, in fact, compatible with the DUT 12 and tester firmware 14a. Additionally, selection of the correct drivers can be confusing and prone to errors, particularly for inexperienced users of the test system 10.
Accordingly, it would be desirable to have a system and method to ensure compatibility among software and drivers used within a test system for wireless transceivers.